home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / eiffel-faq < prev    next >
Text File  |  1994-03-22  |  50KB  |  1,183 lines

  1. Newsgroups: comp.lang.eiffel,comp.answers,news.answers
  2. From: rogerb@eiffel.demon.co.uk (Roger Browne)
  3. Path: bloom-beacon.mit.edu!hookup!news.moneng.mei.com!howland.reston.ans.net!pipex!demon!eiffel.demon.co.uk!rogerb
  4. Organization: Everything Eiffel
  5. Reply-To: rogerb@eiffel.demon.co.uk
  6. Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
  7. Followup-To: comp.lang.eiffel
  8. Expires: +1 month
  9. Approved: news-answers-request@MIT.Edu
  10. Summary: Eiffel is a pure object-oriented language designed to promote
  11.          software correctness and re-use.
  12. Lines: 1165
  13. Date: Tue, 22 Mar 1994 16:14:53 +0000
  14. Message-ID: <764352893snz@eiffel.demon.co.uk>
  15. Sender: usenet@demon.co.uk
  16. Xref: bloom-beacon.mit.edu comp.lang.eiffel:1940 comp.answers:4288 news.answers:16753
  17.  
  18. Archive-name: eiffel-faq
  19. Last-modified: 22 March 1994
  20.  
  21. EIFFEL: FREQUENTLY ASKED QUESTIONS
  22. ----------------------------------
  23.  
  24. This question-and-answer list is posted monthly to the Usenet newsgroups 
  25. comp.lang.eiffel, comp.answers and news.answers.
  26.  
  27. Please send corrections, additions and comments to Roger Browne 
  28. (rogerb@eiffel.demon.co.uk).
  29.  
  30. This information is abstracted and condensed from the posts of many 
  31. contributors to comp.lang.eiffel, supplemented by information from vendors. 
  32. No guarantees are made regarding its accuracy.
  33.  
  34. This compilation is by Roger Browne. Distribution over the Internet or by 
  35. electronic mail is unrestricted. Other use requires my permission.
  36.  
  37. You can receive the latest copy by anonymous file transfer from:
  38.  
  39.    ftp.cm.cf.ac.uk  /pub/eiffel/eiffel-faq
  40.    rtfm.mit.edu     pub/usenet/news.answers/eiffel.faq
  41.  
  42. or by sending an email message to archive-server@cm.cf.ac.uk with the 
  43. following message body:
  44.  
  45.    send Eiffel eiffel-faq
  46.  
  47. ----------
  48.  
  49. CONTENTS
  50.  
  51. Changes since the last posting:
  52.  
  53.    Q01: Minor rewording
  54.    Q07: Bertrand Meyer's new book ("Reusable Software...")
  55.    Q09: New ISE ports (Alpha, Pyramid, NeXTSTEP)
  56.    Q09: New Tower Ports (OS/2, Solaris x86)
  57.    Q14: New information ("How fast is Eiffel")
  58.    Q15: French user group
  59.    Q16: Various changes to Eiffel reseller list
  60.    Q17: Added TOOLS Pacific '94
  61.    L03: Mentioned the Eiffel Booch Components (libraries for TowerEiffel)
  62.  
  63.    Note regarding Q16 (Eiffel Resellers). It appears that EASE, UNIREL and
  64.    SEINCA are no longer active in the Eiffel Market, and I will be removing
  65.    them from the list next month. If anyone has information to the
  66.    contrary, would they please email me.
  67.  
  68.    Thanks to Bertrand Meyer and Rock Howard for their input.
  69.  
  70. Frequently Asked Questions:
  71.  
  72.    Q01) What is Eiffel?
  73.    Q02) Where did Eiffel come from?
  74.    Q03) What Eiffel products are available?
  75.    Q04) Are there any school or student discounts?
  76.    Q05) Is Eiffel available in the public domain?
  77.    Q06) What is Sather? How does it compare to Eiffel?
  78.    Q07) What books are available for learning about Eiffel?
  79.    Q08) Are any magazines or newsletters available concerning Eiffel?
  80.    Q09) Is Eiffel available on PC, Mac, NeXT, Amiga, Atari, ...?
  81.    Q10) Is there an archive of the comp.lang.eiffel newsgroup?
  82.    Q11) How much memory and disk space does Eiffel development require?
  83.    Q12) How large are typical Eiffel executables?
  84.    Q13) Are there standards for the Eiffel language?
  85.    Q14) How fast do Eiffel applications run?
  86.    Q15) Are there any Eiffel user groups?
  87.    Q16) Where can I get Eiffel products and services?
  88.    Q17) Are there any conferences for Eiffel users?
  89.    Q18) Why do Eiffel implementations compile to C?
  90.    Q19) What is BON?
  91.  
  92. Language Issues:
  93.  
  94.    L01) What features does Eiffel have?
  95.    L02) What changes have been made to the Eiffel language definition?
  96.    L03) What libraries come with Eiffel?
  97.    L04) What's the big deal about preconditions and postconditions?
  98.    L05) Please explain and discuss covariance vs. contravariance.
  99.    L06) Is it true that there are "holes" in the Eiffel type system?
  100.    L07) Is there support for concurrency in Eiffel?
  101.    L08) Why doesn't Eiffel allow function overloading?
  102.    L09) Why are there no procedural types in Eiffel?
  103.  
  104. ----------
  105.  
  106. Q01)   What is Eiffel?
  107.  
  108. Eiffel is an advanced object-oriented programming language that emphasizes 
  109. the design and construction of high-quality and reusable software.
  110.  
  111. Eiffel is not a superset or extension of any other language. Eiffel 
  112. strongly encourages object-oriented programming and does not allow 
  113. dangerous practices from previous generation languages although it does 
  114. interface to other languages such as C and C++. Eiffel supports the concept 
  115. of "Design by Contract" to improve software correctness.
  116.  
  117. Beyond the language aspect Eiffel may be viewed as a method of software 
  118. construction. Eiffel is an excellent vehicle for software education, 
  119. including for a first programming course.
  120.  
  121. Eiffel is typically implemented by compilation to C, ensuring wide 
  122. portability.
  123.  
  124. ----------
  125.  
  126. Q02)   Where did Eiffel come from?
  127.  
  128. Eiffel was created by Bertrand Meyer and developed by his company, 
  129. Interactive Software Engineering (ISE) of Goleta, CA.
  130.  
  131. Dr. Meyer borrowed on his extensive experience with OOP, particularly with 
  132. Simula. He also added in important concepts from his academic work on 
  133. software verification and computer language definition.
  134.  
  135. Eiffel's design addresses many practical concerns that software engineers 
  136. face when creating complex software. Eiffel has evolved continually since 
  137. its conception on September 14, 1985 and its first introduction in 1986.
  138.  
  139. ----------
  140.  
  141. Q03)   What Eiffel products are available?
  142.  
  143. ISE Eiffel 3 is a commercially supported product available from Interactive 
  144. Software Engineering.
  145.  
  146. ISE Eiffel 3 is a complete graphical development environment meant for the 
  147. production of quality software, with particular attention being given to 
  148. the development of large systems. The environment itself is written in 
  149. Eiffel, and is an example of non-trivial system - about 3000 classes.
  150.  
  151. A version of Eiffel called Eiffel/S is produced by SIG Computer GmbH of 
  152. Germany. It is based on the Eiffel 3 language definition.
  153.  
  154. Eiffel/S Version 3, release 1.3 includes:
  155.    - command-line compiler with automatic configuration management
  156.    - libraries
  157.    - manual
  158.  
  159. Tower Technology Corporation of Austin, TX produce TowerEiffel. It 
  160. includes:
  161.    - compiler
  162.    - many programming tools
  163.    - an emacs-based integrated programming environment
  164.    - Eiffel 3 kernel and support libraries
  165.  
  166. In addition, there are at least three other Eiffel compiler development 
  167. projects underway. One may release a commercial version of Eiffel 3 in the 
  168. very near future. Availability of high value Eiffel implementations will 
  169. soon be excellent.
  170.  
  171. There is also work going on to create business application development 
  172. environments based on Eiffel, Eiffel CASE-style tools, an Eiffel-based 
  173. OODB.
  174.  
  175. ----------
  176.  
  177. Q04)   Are their any school or student discounts?
  178.  
  179. Both ISE Eiffel and SIG Eiffel/S include aggressive site-licensing and 
  180. discount licenses for schools and universities.
  181.  
  182. Eiffel/S offers an inexpensive student or trial license. This license is 
  183. limited to building systems with up to 75 classes. You do not have to be a 
  184. student to buy it, and you get a discount if you subsequently upgrade to 
  185. the full version.
  186.  
  187. ISE is also selling student licenses on their lower cost platforms.
  188.  
  189. TowerEiffel offers a much reduced price for student, university or non-
  190. commercial licenses.
  191.  
  192. ----------
  193.  
  194. Q05)   Is Eiffel available in the public domain?
  195.  
  196. There is not currently a public domain Eiffel compiler. ISE has expressed 
  197. willingness to support the serious efforts of those who wish to create a PD 
  198. Eiffel, but so far no such effort has succeeded.
  199.  
  200. There is, however, a somewhat limited Eiffel 2.3 interpreter for the Atari 
  201. ST which is shareware (DM50). The documentation is in German, and the 
  202. example files seem quite interesting. Inheritance does not seem to be 
  203. supported (!), but there is an interesting extension to allow "for all" and 
  204. "for some" in assertions.
  205.  
  206. The following Eiffel archive sites allow anonymous file transfer:
  207.  
  208. ftp.tu-clausthal.de
  209. pub/atari/languages/eiffel/vici_102.lzh
  210.    The Atari ST interpreter referred to above.
  211.  
  212. ftp.cm.cf.ac.uk
  213. /pub/eiffel
  214.    University of Wales. Contains the latest version of this FAQ, plus the 
  215.    front-end parser (ep) and various public domain classes. To contribute, 
  216.    contact Ted Lawson (ted@cm.cf.ac.uk).
  217.  
  218. ftp.fu-berlin.de
  219. /pub/heron/ep.tar.Z
  220.    There is an Eiffel front-end parser (HERON) in the public domain, 
  221.    created by Burghardt Groeber and Olaf Langmack of the Freie Universitat 
  222.    in Berlin. Olaf has announced that the Freie Universitat has agreed to 
  223.    join the NICE consortium and keep the front-end parser in sync with the 
  224.    Eiffel language definition as it evolves.
  225.  
  226. ftp.informatik.uni-stuttgart.de
  227. /pub/eiffel
  228.    Falkultaet Informatik der Universitaet Stuttgart, Germany. Contains a 
  229.    compiler generator, several encapsulations, a pretty-printer for 
  230.    Eiffel/S, and some utility classes. To contribute, contact Joerg Schulz 
  231.    (schulz@adam.informatik.uni-stuttgart.de).
  232.  
  233. utarlg.uta.edu
  234. CSE/EIFFEL
  235.    UT-Arlington, USA. Contains some code from Eiffel Outlook back issues.
  236.  
  237. wuarchive.wustl.edu
  238. /graphics/gif/e/eiffel_tower
  239.    Contains a GIF graphic of the eiffel tower
  240.    (also on plaza.aarnet.edu.au from Australia only).
  241.  
  242. ----------
  243.  
  244. Q06)   What is Sather? How does it compare to Eiffel?
  245.  
  246. Sather is an object-oriented language, originally patterned after Eiffel, 
  247. created by Stephen Omohundro and others at ICSI of Berkeley, CA.
  248.  
  249. Sather simplifies some Eiffel constructs, eliminates others, and adds some 
  250. powerful constructs of its own such as iteration abstraction, built-in 
  251. arrays, overloading and object constants.
  252.  
  253. Sather is available for free, under a very unrestrictive license. The 
  254. documentation for Sather, and the ICSI implementation of it, are available 
  255. by anonymous file transfer from the following sites:
  256.  
  257.    ftp.ICSI.Berkeley.edu   /pub/sather
  258.    ftp.gmd.de              /pub/Sather
  259.    sra.co.jp               /pub/lang/sather
  260.    lynx.csis.dit.csiro.au  /pub/sather
  261.  
  262. See the usenet newsgroup comp.lang.sather for more details.
  263.  
  264. ----------
  265.  
  266. Q07)   What books are available for learning about Eiffel?
  267.  
  268. The classic text for learning about Eiffel (as well as Object-Oriented 
  269. programming in general) is Dr. Meyer's "Object Oriented Software 
  270. Construction". Although the language has evolved significantly since the 
  271. book's date of publication, the presentation of the basic problems and 
  272. solutions which motivate the object-oriented mind set are still quite 
  273. compelling. This is the book to get if you are new to the object-oriented 
  274. world as well as to Eiffel. (Prentice Hall, ISBN 13-629031-0)
  275.  
  276. Also by Dr. Meyer, "Eiffel: The Language", combines an introduction to 
  277. Eiffel, the language reference, and a good deal of philosophy into its 600 
  278. pages. This is the state of the art in OO thinking, but is a rigorous and 
  279. comprehensive book which some readers may find heavy going despite Dr. 
  280. Meyer's clarity of expression. It is, however, the definitive language 
  281. reference, and essential reading for all serious Eiffel users. This book is 
  282. now in its second _printing_ (same ISBN), with some minor corrections and 
  283. clarifications (this is not a second _edition_, and none is currently 
  284. underway). (Prentice Hall, ISBN 13-247925-7)
  285.  
  286. Dr. Meyer and Jean-Marc Nerson have edited a new book about Eiffel called 
  287. "Object-Oriented Applications". It includes an introduction to Eiffel 
  288. technology followed by seven in-depth descriptions of large applications 
  289. written in Eiffel. (Prentice Hall, ISBN 13-013798-7)
  290.  
  291. Robert Switzer, from Gottingen University in Germany, has written "Eiffel: 
  292. An Introduction". This is a very clear and concise primer for those wishing 
  293. to learn Eiffel, with many code fragments, and two substantial Eiffel 
  294. applications. (Prentice Hall, ISBN 13-105909-2)
  295.  
  296. ISE distributes a set of 6 video lectures (about one hour each) entitled 
  297. "Object-Oriented Software Construction", taught by Bertrand Meyer. These 
  298. provide an overall introduction to the method and use ISE Eiffel 3 to 
  299. illustrate the concepts.
  300.  
  301. Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in der 
  302. Praxis" is a very down-to-earth Eiffel handbook for German speakers. 
  303. (Heise, ISBN 3-88229-028-5).
  304.  
  305. Bertrand Meyer's "Reusable Software: The Base Object-Oriented Component 
  306. Libraries" (Prentice Hall, ISBN 0-13-245499-8, about 530 pages) describes 
  307. principles of library design and the taxonomy of fundamental computing 
  308. structures that led to ISE's EiffelBase libraries. Also serves as a manual 
  309. for the EiffelBase libraries.
  310.  
  311. ----------
  312.  
  313. Q08)   Are any magazines or newsletters available concerning Eiffel?
  314.  
  315. Eiffel Outlook is a bi-monthly newsletter devoted to Eiffel and Sather. It 
  316. is 24 pages long and focuses mainly on practical and technical issues
  317. involved in using these languages. Contact Tower Technology Corporation for 
  318. more information. Trial subscriptions and back issues are available.
  319.  
  320. Eiffel Outlook is distributed by:
  321.  
  322.    Jay-Kell in Canada
  323.    SIG Computer in Germany
  324.    Everything Eiffel in the United Kingdom and France
  325.    Simon Parker in Ireland
  326.    IMSL in Japan
  327.    Enea Data in Sweden
  328.    Class Technology in Australia
  329.    Tower Technology in the USA and for all other countries
  330.  
  331. Eiffel Post is a four page newsletter (in German) for customers of SIG 
  332. Computer, the makers of Eiffel/S.
  333.  
  334. The Eiffel Interest Group of the UK and Ireland publishes an excellent 
  335. newsletter for its members.
  336.  
  337. NICE has produced a four-page glossy flyer "Eiffel Success Stories", 
  338. intended to be the first of a series.
  339.  
  340. ISE produces an 8-page newsletter "Eiffel World" which will appear several 
  341. times a year.
  342.  
  343. ----------
  344.  
  345. Q09)   Is Eiffel available on PC, Mac, NeXT, Amiga, Atari, ...?
  346.  
  347. This is the latest information that I have, but it does change rapidly.
  348.  
  349. SIG Eiffel/S 1.3 is available for DOS on the PC. As at January 1994, the 
  350. following C compilers are supported: Microsoft C 7.0, Borland C++ 3.x, Gnu 
  351. 2.2.2 (with DJ Expander), Gnu 2.4.5 (with emx-g expander), Symantec C++ 
  352. 6.0, Watcom 9.5. SIG uses Symantec in-house. It works best with a 32-bit 
  353. compiler, e.g. Gnu, Symantec, Watcom.
  354.  
  355. Eiffel/S 1.3 is also available for OS/2 (using GCC 2.4.5 emx-g, Watcom C 
  356. 9.5 or IBM C/Set) and Windows/NT (Microsoft 32-bit C, Watcom C 9.5 or 
  357. Symantec C++ 6.0), and for the following Unix systems: Linux, PC Unix 
  358. (Interactive, SCO, and ESIX), SPARC, NeXT, NeXTstep-Intel, HP/9000, DEC 
  359. 5xxx, Sony News, DG Aviion and RS/6000.
  360.  
  361. ISE's Eiffel 3 (Release 3.2) is available for DEC Alpha, DEC Ultrix, DG 
  362. Aviion (and hence other 88Open platforms), Fujitsu, HP UX, IBM RS/6000, 
  363. Pyramid, SCO (Open Desktop), Silicon Graphics and Sparc (Solaris 2.3 or 
  364. SunOS). NeXTSTEP (Intel and Motorola) is also available (for EiffelBench 
  365. only, so far). The VMS version is nearing completion. Development is 
  366. underway for other platforms.
  367.  
  368. Tower Corporation's TowerEiffel (Release 1.2) is available on Sun SPARC or 
  369. compatible running SunOS 4.1.x with gcc 2.2.2, gcc 2.4.5 or Sun's acc 2.0.1 
  370. C compiler; also running Solaris 2.1 with gcc 2.4.5. A preliminary version 
  371. is available for OS/2 and Solaris x86. Ports to NeXT 486 and Windows NT are 
  372. underway.
  373.  
  374. Future ports of TowerEiffel are planned for AIX, IRIX, HPUX, DG/UX, 
  375. NextStep, Windows NT, OS/2, VMS and various Intel-based Unix systems.
  376.  
  377. ----------
  378.  
  379. Q10)   Is there an archive of the comp.lang.eiffel newsgroup?
  380.  
  381. An archive of the newsgroup is available on gatekeeper.dec.com. The DEC 
  382. Western Research Lab hosts it. This archive does not contain articles after 
  383. September 1992.
  384.  
  385. The files are in /pub/plan/eiffel/usenet/USENET-xx-yyy, where `xx' 
  386. represents the last two digits of the year and `yyy' the month of posting, 
  387. e.g., /pub/plan/eiffel/usenet/USENET-91-AUG. Compressed versions of the 
  388. files are also available.
  389.  
  390. >From IP (either inside DEC or outside DEC):
  391.    anonymous FTP to gatekeeper.dec.com (16.1.0.2)
  392.    cd pub/plan/eiffel/usenet
  393.    get USENET-xx-yyy
  394.    (or to get the compressed copy, bin, get USENET-xx-yyy.Z)
  395.  
  396. >From a UUCP neighbor of decwrl:
  397.    "uucp decwrl!~/pub/plan/eiffel/usenet/USENET-xx-yyy.Z"
  398.  
  399. >From the DEC Easynet:
  400.    DECWRL::"/pub/plan/eiffel/usenet/USENET-xx-yyy"
  401.  
  402. USENET-88-DEC and USENET-88-DEC.Z are the oldest entries in the archives.
  403.  
  404. There is also an archive of comp.lang.eiffel at wuarchive.wustl.edu (login 
  405. as anonymous, send e-mail address as password). The files are in 
  406. /usenet/comp.lang.eiffel and subdirectories. Each message is in a separate 
  407. file, so it's not as convenient as the DEC archive, but it's more up-to-
  408. date.
  409.  
  410. ----------
  411.  
  412. Q11)   How much memory and disk space does Eiffel development require?
  413.  
  414. To install and run Eiffel/S 1.3, you need 10MB of disk space and at least 
  415. 4MB RAM (8MB recommended).
  416.  
  417. However, for serious Eiffel work you could easily use 100MB or more.
  418.  
  419. ----------
  420.  
  421. Q12)   How large are typical Eiffel executables?
  422.  
  423. (How large are typical C executables?)
  424.  
  425. Seriously, Eiffel does impose a minimum size which is large since even 
  426. trivial Eiffel applications bring in a lot of classes. So, a simple program 
  427. like "Hello World" will create a relatively large executable.
  428.  
  429. Interestingly, Eiffel applications seem to grow less rapidly as new 
  430. capabilities are added. Reuse does help out tremendously in this regard. A 
  431. good Eiffel compiler allows large applications to be smaller than equally 
  432. functional applications written in C.
  433.  
  434. Note that leaving assertion checking in the code increases the size of 
  435. applications a lot. Despite this, many of us prefer that they remain 
  436. throughout development. Some even deliver a PRECONDITIONS-only version of 
  437. their applications to their early customers.
  438.  
  439. ----------
  440.  
  441. Q13)   Are there standards for the Eiffel language?
  442.  
  443. The definition of the Eiffel language is in the public domain. This 
  444. definition is controlled by NICE, the Non-profit International Consortium 
  445. for Eiffel. This means that anyone or any company may create a compiler, 
  446. interpreter, or whatever having to do with Eiffel. NICE reserves the right 
  447. to validate that any such tool conforms to the current definition of the 
  448. Eiffel language before it can be distributed with the Eiffel trademark. 
  449. (i.e. advertised as an "Eiffel" compiler.)
  450.  
  451. The Eiffel trademark is owned and controlled by NICE. NICE is using Dr. 
  452. Meyer's latest book, "Eiffel: The Language", as the initial definition of 
  453. the language.
  454.  
  455. The NICE board of directors consists of Bertrand Meyer, Darcy Harrison, 
  456. Frieder Monninger, Peter Williams and Rock Howard (chairman).
  457.  
  458. NICE has formed the Eiffel Standards Group (ESG) to resolve standards 
  459. questions and control the evolution of the language. The three current 
  460. Eiffel Compiler Vendors (ISE, SIG and Tower) are represented in the ESG as 
  461. well as many important and influential users of Eiffel.
  462.  
  463. There are three committees -- Language, Library, and Future Directions.
  464.  
  465. The Language Committee will address the ambiguities in the Eiffel Version 3 
  466. language specification as well as the differences that appear between the 
  467. current Eiffel 3 implementations.
  468.  
  469. The Library Committee will standardize the Kernel library, then consider 
  470. interface standards for the data structures cluster and other key Eiffel 
  471. clusters.
  472.  
  473. The Future Requirements Committee will prioritize the long range direction 
  474. of the standards work performed by the other two committees.
  475.  
  476. The NICE Interoperability Program (NIP) tracks the reporting and resolution 
  477. of interoperability problems. If you are aware of a problem whereby correct 
  478. Eiffel code will not run under a particular implementation, or where 
  479. correct Eiffel code produces different results under different 
  480. implementations, you are invited to report this by email to 
  481. nice-nip@atlanta.twr.com
  482.  
  483. NICE (Nonprofit International Consortium for Eiffel)
  484. 2701 Stratford Drive
  485. Austin, TX 78746
  486. TEL: (512) 328 6406
  487. FAX: (512) 328 0466
  488. email: nice@twr.com
  489.  
  490. ----------
  491.  
  492. Q14)   How fast do Eiffel applications run?
  493.  
  494. Early versions of Eiffel were slow. Recent implementations have improved 
  495. dramatically. However, to achieve maximum performance under any Eiffel 
  496. implementation, run-time assertion monitoring must be switched off.
  497.  
  498. It's hard to generalise, but compared to C++, simple computation-intensive 
  499. applications will run perhaps 15% slower. Large applications are often 
  500. dominated by memory management rather than computation. ISE recently 
  501. demonstrated that by simply adding a call to the garbage collector's "full-
  502. collect" routine at a time when there were known to be few live objects,
  503. performance became dramatically faster than a corresponding C++ version.
  504.  
  505. ----------
  506.  
  507. Q15)   Are there any Eiffel user groups?
  508.  
  509. International Eiffel                 UK & Ireland Eiffel Interest Group
  510.   User Group (IEUG)                  Caroline Browne
  511. Darcy Harrison - Attention: IEUG     9 Princeton Court
  512. ISE Inc.                             55 Felsham Road
  513. 270 Storke Road, Suite 7             London SW15 1AZ
  514. Goleta, CA 93117, USA                TEL 081 780 1088
  515. TEL (805) 685-1006                   FAX 081 780 1941
  516. FAX (805) 685-6869                   (publishes a newsletter and holds
  517. email darcyh@eiffel.com               a quarterly meeting and seminar)
  518.  
  519. GUE, Groupe des Utilisateurs Eiffel (France)
  520. Jean-Marc Nerson
  521. 104 rue Castagnary, 75015 Paris
  522. TEL +33 1 45 32 58 80
  523. FAX +33 1 44 32 58 81
  524. email marc@eiffel.fr
  525. (meets every two months or so)
  526.  
  527. ----------
  528.  
  529. Q16)   Where can I get Eiffel products and services?
  530.  
  531. Interactive Software Engineering, Inc.  Jay-Kell Technologies, Inc.
  532. 270 Storke Road, Suite 7                48 Lakeshore Road, Suite #1
  533. Goleta, CA 93117                        Pointe Claire, Quebec
  534. TEL 805-685-1006                        Canada H9S 4H4
  535. FAX 805-685-6869                        TEL +51 4 630 1005
  536. email info@eiffel.com                   FAX +51 4 630 1456
  537.  
  538. SIG Computer GmbH                       Tower Technology Corporation
  539. zu den Bettern 4                        1501 Koenig Lane
  540. D 35619 Braunfels, Germany              Austin, TX 78756 USA
  541. TEL +49 6472 2096, FAX +49 6472 7213    TEL 512-452-9455
  542. email eiffel@sigcomp.de                 FAX 512-452-1721
  543. (cyrillic email eiffel@sigcomp.msk.su)  email: tower@twr.com
  544.  
  545. Class Technology Pty. Ltd.              Ease Pty. Ltd.
  546. 6 Pound Road                            4 Edinburgh Avenue
  547. Hornsby NSW 2077, Australia             Carlingford NSW 2118
  548. TEL +61 2 477 6188                      Australia
  549. FAX +61 2 476 4378                      TEL +61 2 683 6930
  550. email class@peg.pegasus.oz.au           FAX +61 2 630 8717
  551.  
  552. Everything Eiffel                       Applied Logic Group
  553. 6 Bambers Walk                          9 Princeton Court
  554. Wesham PR4 3DG                          55 Felsham Road
  555. England                                 London SW15 1AZ, England
  556. TEL +44 772 687525                      TEL +44 81 780 1988
  557. email rogerb@eiffel.demon.co.uk         FAX +44 81 780 1941
  558.  
  559. EtnoTeam                                SOL
  560. Via Adelaide Bono Cairoli 34            104 rue Castagnary
  561. 20217 Milano                            75015 Paris
  562. Italy                                   France
  563. TEL +39 2 261621                        TEL +33 1 45 32 58 80
  564. FAX +39 2 26110755                      FAX +33 1 44 32 58 81
  565.  
  566. Unirel                                  Sritech Information Technology
  567. Centro Comerciale Osmanoro              744/51 2nd Floor
  568. Via Volturno, 12                        10 Mian Road, 4th Block
  569. 50019 Sesto Fiorentino (FL)             Jayanagar, Bangalore
  570. Italy                                   India 560011
  571. TEL +39 55 373043                       TEL +91 812 640661
  572. FAX +39 55 318525                       FAX +91 812 643608
  573.  
  574. Cromasoft, SA de CV                     Objective Methods Ltd
  575. Mazatlan 161                            PO Box 17356 (77 Chamberlain Rd)
  576. Col Condesa, 06140 Mexico               Karori, Wellington, New Zealand
  577. TEL +52 5 286 82 13                     TEL +64 4 476 9499
  578. FAX +52 5 286 80 57                     FAX +64 4 476 9237 or 8772
  579. email claudio@croma.sunmexico.sun.com   email dkenny@swell.actrix.gen.nz
  580.  
  581. Seinca                                  Enea Data
  582. C/Jorge Juan, 19 - #4                   Box 232, Nytorpsvagen 5
  583. 28001 Madrid                            S-183 23 Taby, Sweden
  584. Spain                                   TEL +46 8 792 25 00
  585. TEL +34 1 577 99 95                     FAX +46 8 768 43 88
  586. FAX +34 1 577 49 81                     email eiffel@enea.se
  587.  
  588. Cybertech                               Forefront Computer Services
  589. Systens Integration for CIM               Pty. Ltd.
  590. Suarez 1281, Third Floor,Apt.A          115 Seaford Road
  591. CP-1288 Buenos Aires                    Seaford, Victoria 3198
  592. Argentina                               Australia
  593. TEL +54 1 28 1950                       TEL +61 3 785 1122
  594. FAX +54 1 322 1071 or +54 1 963 0070    FAX +61 3 770 0961
  595.  
  596. SOOPS                                   Software Research Associates
  597. Sarphatistraat 133                      1-1-1 Hirakawo-Cho
  598. NL-1018 GC Amsterdam, The Netherlands   Chiyoda-ku Tokyo 102, Japan
  599. TEL +31 20 525 6644                     TEL +81 3 3234 2623
  600. FAX +31 20 624 6392                     FAX +81 3 3234 4338
  601. email A731CISK@HASARA11.BITNET
  602.  
  603. Information and Mathematical Science    Simon Parker
  604.   Laboratory, Inc.                      45 Hazelwood
  605. 2-43-1, Ikebukuro, Toshima-ku           Shankill
  606. Tokyo 171, Japan                        Co Dublin
  607. email fushimi@idas.imslab.co.jp         Ireland
  608. TEL +81 3 3590 5211                     TEL +353 1 282 3487
  609. FAX +81 3 3590 5353                     email sparker@chl.ie
  610.  
  611. Objectif Concept                        Abstraction (Jacques Silberstein)
  612. Passage Cour-Robert 5                   18 Faubourg de l'Hopital
  613. CH 1700 Fribourg, Switzerland           2000 Neuchatel, Switzerland
  614. TEL (41) 37-232977                      phone +41.38.25.04.93
  615. FAX (41) 37-464889                      fax +41.38.259.857
  616.                                         email 100015.304@compuserve.com
  617.  
  618. ZumaSoft
  619. 6235 Paseo Canyon Drive
  620. Malibu, California 90265, USA
  621. TEL & FAX +1 310 457-6263
  622. email 72674.3161@compuserve.com
  623.  
  624. ----------
  625.  
  626. Q17)   Are there any conferences for Eiffel users?
  627.  
  628. The conferences listed here are not just for Eiffel. Eiffel shares the 
  629. spotlight with other object-oriented languages including C++ and Smalltalk.
  630.  
  631. Aug 1 - 5, 1994
  632.    TOOLS USA '94, Santa Barbara, California
  633.    Deadline for papers: 18 March
  634.  
  635. Nov 29 - Dec 1, 1994
  636.   TOOLS PACIFIC '94, Melbourne, Australia
  637.   Deadline for papers: 22 July
  638.  
  639. TOOLS is the major international conference devoted to the applications of 
  640. Object-Oriented technology. Other events, such as Eiffel User Group 
  641. meetings or NICE meetings are often held in conjunction with TOOLS.
  642.  
  643. TOOLS Conferences
  644. PO Box 6863, Santa Barbara, CA 93160, USA
  645. TEL (805) 685 1006, FAX (805) 685 6869
  646. email tools@tools.com
  647.  
  648. ----------
  649.  
  650. Q18)   Why do Eiffel implementations compile to C?
  651.  
  652. (Although current Eiffel implementations compile to C or C++, native code 
  653. compilers may become available in the future.)
  654.  
  655. By using C as a target language, an Eiffel implementor can:
  656.  
  657. -  bring Eiffel to the marketplace faster and at lower cost
  658. -  port their implementation more easily to other platforms
  659. -  take advantage of optimisation provided by the C compiler
  660.  
  661. Much of the technology that makes Eiffel relatively simple to use also 
  662. makes it more difficult to implement (an Eiffel-to-C compiler is perhaps 4 
  663. to 5 times more difficult to create than a native Pascal compiler).
  664.  
  665. Compiling Eiffel to C seems to work well under Unix. C is sometimes thought 
  666. of as the native code of Unix.
  667.  
  668. On the other hand, C is not universal on other platforms, and the Eiffel 
  669. purchaser may need to buy a C compiler as well, and possibly replace it if 
  670. the supported C compilers change with new versions of the Eiffel compiler.
  671.  
  672. With a native-code compiler, you'd get somewhat better throughput and the 
  673. potential for smaller executables and slightly better performance. You'd 
  674. also get a higher price and an even longer wait for Eiffel to show up on 
  675. other than the leading market share machines.
  676.  
  677. ----------
  678.  
  679. Q19)   What is BON?
  680.  
  681. BON ("Business Object Notation") is a method for high-level analysis and 
  682. design, offering a seamless transition to an Eiffel implementation. The 
  683. method emphasizes Design by Contract and systematic development. For more 
  684. information on BON, see the Communications of the ACM, September 1992.
  685.  
  686. ----------
  687.  
  688. L01)   What features does Eiffel have?
  689.  
  690. Eiffel is a pure object-oriented language. Its modularity is based on 
  691. classes. It stresses reliability, and facilitates design by contract. It 
  692. brings design and programming closer together. It encourages the re-use of 
  693. software components.
  694.  
  695. Eiffel offers classes, multiple inheritance, polymorphism, static typing 
  696. and dynamic binding, genericity (constrained and unconstrained), a 
  697. disciplined exception mechanism, systematic use of assertions to promote 
  698. programming by contract, and deferred classes for high-level design and 
  699. analysis.
  700.  
  701. Eiffel has an elegant design and programming style, and is easy to learn.
  702.  
  703. ----------
  704.  
  705. L02)   What changes have been made to the Eiffel language definition?
  706.  
  707. Eiffel is still a relatively new language, and there have been a number of 
  708. changes to its definition. Here is a summary of the major changes:
  709.  
  710. 1. Changes between the publication of "Object-Oriented Software 
  711.    Construction" in 1988, and the release of Eiffel 2.3:
  712.  
  713.    - Constrained genericity enables a generic class to restrict its
  714.      generic parameters to the descendants of a given class
  715.  
  716.    - The indexing clause allows information about a class to be
  717.      recorded for extraction by archival, browsing and query tools
  718.  
  719.    - The assignment attempt operator "?=" provides a way to make
  720.      type-safe assignments going against the inheritance hierarchy
  721.  
  722.    - User-defined infix and prefix operator features
  723.  
  724.    - Expanded types support composite objects without dynamic
  725.      allocation, and with value semantics
  726.  
  727.    - The obsolete clause for smooth library evolution
  728.  
  729.    - The unique keyword for implicitly-assigned integer codes
  730.  
  731.    - The multi-branch instruction (similar to a case statement)
  732.  
  733.    - The boolean operator for implication ("implies")
  734.  
  735. 2. Changes with the introduction of Eiffel Version 3:
  736.  
  737.    - The feature adaptation subclause must now be terminated with "end"
  738.  
  739.    - Semicolons as instruction separators are optional
  740.  
  741.    - Groups of features are bracketed by a feature clause. All features
  742.      are exported unless the feature clause specifies a restriction.
  743.      The repeat subclause is no longer needed, because inherited
  744.      features keep the original export status they had in the parent
  745.      unless they are redefined, or are the subject of an export
  746.      subclause in the feature adaptation clause.
  747.  
  748.    - Preconditions can only be replaced by weaker ones, postconditions
  749.      can only be replaced by stronger ones. This is now enforced by the
  750.      language through the use of "require else" in preconditions and
  751.      "ensure then" in postconditions.
  752.  
  753.    - Ambiguities in repeated inheritance are resolved by a select
  754.      clause.
  755.  
  756.    - A feature can no longer be replicated and redefined in the same
  757.      feature adaptation clause, however the same effect can be achieved
  758.      through repeated inheritance
  759.  
  760.    - Two or more features may be defined at the same time (e.g. "f1, f2
  761.      is...").
  762.  
  763.    - The keyword "frozen" before a feature name prohibits redefinition
  764.      of the feature in descendants
  765.  
  766.    - In an anchored declaration, the anchor may now also be a formal
  767.      argument of the enclosing routine
  768.  
  769.    - A class may have zero, one or more creation procedures, designated
  770.      with the "creation" keyword. A new creation syntax using the "!!"
  771.      symbol allows the appropriate creation procedure to be specified.
  772.      It is also possible to directly create an object of any type which
  773.      conforms to the entity to which it is being attached.
  774.  
  775.    - The meaning of dot notation has been made more uniform, and
  776.      alternative constructs have been provided for the special
  777.      language-defined features that previously used dot notation:
  778.          x.Create   is now  !! x
  779.          y.Clone(x) is now  y := clone(x)
  780.          x.Forget   is now  x := Void
  781.          x.Void     is now  x = Void
  782.          x.Equal(y) is now  equal(x, y)
  783.  
  784.    - Manifest arrays can be specified, for example
  785.          <<"Jan", "Feb", "Mar">>
  786.      which also provides a way to pass a variable number of arguments
  787.      to a routine.
  788.  
  789.    - The command-line parameters are made available to the creation
  790.      procedure of the root class as an array of strings.
  791.  
  792.    - A default rescue procedure called default_rescue may be defined
  793.      and inherited.
  794.  
  795.    - A class may be declared to be an expanded class, in which case any
  796.      type based on that class will be expanded.
  797.  
  798.    - An object may no longer contain a reference to an expanded object
  799.      that is a sub-object of another object. Instead, upon assignment
  800.      of an expanded object to a non-expanded object, the expanded
  801.      object will be cloned, and a reference to the newly-cloned object
  802.      will be stored in the non-expanded object.
  803.  
  804.    - The operator "div" has been replaced by "//", and the operator
  805.      "mod" has been replaced by "\\".
  806.  
  807. 3. Changes between first and second printings of "Eiffel: The Language"
  808.  
  809.    - New basic types INTEGER_REF, REAL_REF, CHARACTER_REF and
  810.      BOOLEAN_REF etc have been introduced to provide non-expanded basic
  811.      types.
  812.  
  813.    - Introduction of the POINTER type to enable external references to
  814.      be passed around in Eiffel programs.
  815.  
  816.    - Calls from Eiffel to external routines no longer implicitly pass
  817.      the current object as the first parameter.
  818.  
  819. ----------
  820.  
  821. L03)   What libraries come with Eiffel?
  822.  
  823. ISE Eiffel 3:
  824.  
  825. EiffelBase (the basic library) is a library of reusable components covering 
  826. data structures and algorithms. It is the result of long-going systematic 
  827. effort at classifying the fundamental patterns and structures of computer 
  828. science in a Linnaean manner. It relies heavily on the Eiffel method, in 
  829. particular assertions (preconditions, postconditions, class invariants), 
  830. Design by Contract, constrained genericity, and repeated inheritance.
  831.  
  832. EiffelVision (the GUI library) is an encapsulation of essential graphical 
  833. abstractions. It makes it possible to build graphical Eiffel applications 
  834. without having to learn and use the internal details of X, Motif, OpenLook 
  835. or other window systems, as they are all encapsulated in EiffelVision's 
  836. classes in a form that is closer to application-related concepts.
  837.  
  838. EiffelLex provides a set of lexical analysis facilities.
  839.  
  840. EiffelParse (still in a somewhat provisional state) is an object-oriented 
  841. approach to parsing.
  842.  
  843. Other libraries are under development; in particular, third-party
  844. products are being integrated into the EiffelShelf distribution.
  845. (If you are interested in submitting components to the EiffelShelf,
  846. for profit or just for fame, please contact shelf@eiffel.com)
  847.  
  848. SIG Eiffel/S:
  849.  
  850.    The universal classes -- GENERAL, PLATFORM, ANY and NONE
  851.  
  852.    The special classes, some of which are treated specially by the compiler 
  853.    -- PART_COMPARABLE, COMPARABLE, NUMERIC, HASHABLE, BOOLEAN, CHARACTER, 
  854.    INTEGER, REAL, DOUBLE, ARRAY, BITS n, OBJECT_STRUCTURE and STRING
  855.  
  856.    ENVIRONMENT -- provides access to command line arguments and environment 
  857.    variables
  858.  
  859.    BASIC_IO -- access to standard input, standard output and error output 
  860.    serial I/O
  861.  
  862.    FORMAT -- conversion of other data types to and from strings
  863.  
  864.    EXCEPTION -- fine grained access to exception handling
  865.  
  866.    SYSTEM_TIME -- system time interface
  867.  
  868.    INTERNAL -- control of the garbage collector
  869.  
  870.    The FILES cluster: FILE, FILE_SYSTEM, FSYS_DAT -- files are modelled as 
  871.    persistent dynamic arrays
  872.  
  873.    TEXTFILE -- treats an ASCII text file as an array of strings
  874.  
  875.    The SORTER class -- a sorting 'expert' that knows how to sort arrays 
  876.    optimally
  877.  
  878.    The MATH class -- trig, log, truncation, and a few constants
  879.  
  880.    The basic container classes -- classified according to uniqueness (can 
  881.    the same object occur more than once in the container?), ordering (are 
  882.    objects in the container kept in sorted order?) and search access (does 
  883.    one search for a key, or for the object itself?), as well as by 
  884.    efficiency (is speed or size more important?): LIST, SORTED_LIST, 
  885.    SIMPLE_TABLE, HASH_TABLE, SORTED_TABLE, SHORT_LIST, SHORT_TABLE, 
  886.    SHORT_SORTED_LIST and SHORT_SORTED_TABLE
  887.  
  888.    Other container classes -- associative arrays accessed by a hashable 
  889.    key: DICTIONARY (with unique keys) and CATALOG (with multiple items per 
  890.    key)
  891.  
  892.    Specialised container classes -- STACK, QUEUE, PRIORITY_QUEUE and 
  893.    KEY_PRIORITY_QUEUE
  894.  
  895.    Abstract container classes -- define much of the interface of 
  896.    containers: COLLECTION, TABLE, SORTED_COLLECTION and SORT_TABLE.
  897.  
  898.    Iterator classes -- objects stored within containers can be visited 
  899.    sequentially with iterators. More than one iterator can be active on a 
  900.    container at one time: TRAVERSABLE, TWOWAY_TRAVERSABLE, ITERATOR and 
  901.    TWOWAY_ITER.
  902.  
  903.    The GRAPH Cluster -- a graph is defined by the classes VERTEX and EDGE. 
  904.    It may have weighted edges (WT_GRAPH) or unweighted edges (GRAPH). 
  905.    Iterators are provided to visit the edges emanating from a vertex 
  906.    (EDGE_ITER); or all the vertices of a graph in breadth-first order 
  907.    (BREADTH_ITER), depth-first order (DEPTH_ITER) or topological order 
  908.    (TOP_ITER).
  909.  
  910.    The MATCHER Cluster -- the MATCHER class is a pattern matcher that can 
  911.    build and activate an automaton to search for patterns in text. 
  912.    Effective descendants search for text using the Rabin-Karp algorithm 
  913.    (RK_MATCHER), the Knuth-Morris-Pratt algorithm (KMP_MATCHER) and the 
  914.    Boyer-Moore algorithm (BM_MATCHER). Others search for Regular 
  915.    Expressions (RE_MATCHER) and lists of keywords (KEYWORD_MATCHER). 
  916.    TXT_MATCHER is an iterator that searches for multiple occurrences of a 
  917.    pattern in an array of strings, using any of the matcher classes.
  918.  
  919.    The documentation is brief but readable, including examples and hints 
  920.    for adding new containers or matchers. All in all, a smaller but 
  921.    possibly tighter set of libraries.
  922.  
  923. (This response may give the appearance that Eiffel/S libraries are much
  924. more extensive than ISE's, but the converse is true.)
  925.  
  926. The Eiffel Booch Components are available for use with TowerEiffel. Most of 
  927. them can be made safe in the presence of multiple threads of control. They 
  928. come with testing classes which double as training aids. They include:
  929.  
  930.   Data Structures
  931.     Bags, collections, deques, dictionaries, graphs, lists, maps, queues, 
  932.     rings, sets, stacks and trees.
  933.  
  934.   Tools
  935.     Pattern-matching, search, sort.
  936.  
  937.   Support Classes
  938.     Node, hash table, dictionary, synchronisation, date and time.
  939.  
  940. ----------
  941.  
  942. L04)   What's the big deal about preconditions and postconditions?
  943.  
  944. The big deal is that it supports programming by contract. For example, 
  945. preconditions (require clauses) are simple boolean statements that are used 
  946. to check that the input arguments are valid and that the object is in a 
  947. reasonable state to do the requested operation. If not, an exception is 
  948. generated. Similarly, postconditions (ensure clauses) make sure that a 
  949. method has successfully performed its duties, thus "fulfilling its 
  950. contract" with the caller. Invariants are boolean expressions that are 
  951. checked every time an object method returns back to a separate object.
  952.  
  953. You can use these ideas in any object-oriented programming language, but 
  954. usually must supply your own assertion mechanisms or rely on programmer 
  955. discipline. In Eiffel, the ideas are integrated into the whole fabric of 
  956. the environment. We find them used by:
  957.  
  958. -- the exception handling mechanism.
  959.    (Tracebacks almost always identify the correct culprit code since 
  960.    preconditions almost always denote an error in the calling method, while 
  961.    postconditions denote an error in the called method.)
  962.  
  963. -- the automatic compilation system.
  964.    (Assertions can be disabled entirely or selectively by type on a per 
  965.    class basis.)
  966.  
  967. -- the Eiffel compiler
  968.    (Invariants, preconditions and postconditions are all inherited in a 
  969.    manner that makes logical sense.)
  970.    (Assertion expressions are not allowed to produce side effects so they 
  971.    can be omitted without effect.)
  972.  
  973. -- the automatic documentation tools
  974.    (Preconditions and postconditions are important statements about what a 
  975.    method does, often effectively describing the "contract" between the 
  976.    caller and callee. Invariants can yield information about legal states 
  977.    an object can have.)
  978.  
  979. In the future we expect to see formal methods technology work its way into 
  980. the assertion capability. This will allow progressively more powerful 
  981. constraints to be put into place. In addition, if a conjecture by Dr. Meyer 
  982. bears fruit, the notion of preconditions may be extended into an important 
  983. mechanism for the development of parallel programming.
  984.  
  985. ----------
  986.  
  987. L05)   Please explain and discuss covariance vs. contravariance.
  988.  
  989. Consider the following situation: we have two classes PARENT and CHILD. 
  990. CHILD inherits from PARENT, and redefines PARENT's feature 'foo'.
  991.  
  992.    class PARENT
  993.       feature
  994.          foo (arg: A) is ...
  995.    end; -- PARENT
  996.  
  997.    class CHILD
  998.       inherit
  999.          PARENT redefine foo
  1000.       feature
  1001.          foo (arg: B) is ...
  1002.     end; -- CHILD
  1003.  
  1004. The question is: what restrictions are placed on the type of argument to 
  1005. 'foo', that is 'A' and 'B'? (If they are the same, there is no problem.)
  1006.  
  1007. Here are two possibilities:
  1008.  
  1009.    (1)  B must be a child of A (the covariant rule - so named because in 
  1010.         the child class the types of arguments in redefined routines are 
  1011.         children of types in the parent's routine, so the inheritance 
  1012.         "varies" for both in the same direction)
  1013.  
  1014.    (2)  B must be a parent of A (the contravariant rule)
  1015.  
  1016. Eiffel uses the covariant rule.
  1017.  
  1018. At first, the contravariant rule seems theoretically appealing. Recall that 
  1019. polymorphism means that an attribute can hold not only objects of its 
  1020. declared type, but also of any descendant (child) type. Dynamic binding 
  1021. means that a feature call on an attribute will trigger the corresponding 
  1022. feature call for the *actual* type of the object, which may be a descendant 
  1023. of the declared type of the attribute. With contravariance, we can assign 
  1024. an object of descendant type to an attribute, and all feature calls will 
  1025. still work because the descendant can cope with feature arguments at least 
  1026. as general as those of the ancestor. In fact, the descendant object is in 
  1027. every way also a fully-valid instance of the ancestor object: we are using 
  1028. inheritance to implement subtyping.
  1029.  
  1030. However, in programming real-world applications we frequently need to 
  1031. specialize related classes jointly.
  1032.  
  1033. Here is an example, where PLOT_3D inherits from PLOT, and DATA_SAMPLE_3D 
  1034. inherits from DATA_SAMPLE.
  1035.  
  1036.    class PLOT
  1037.       feature
  1038.          add(arg: DATA_SAMPLE) is ...
  1039.  
  1040.    class PLOT_3D
  1041.       inherit
  1042.          PLOT redefine add
  1043.       feature
  1044.          add(arg: DATA_SAMPLE_3D) is ...
  1045.  
  1046. This requires the covariant rule, and works well in Eiffel.
  1047.  
  1048. It would fail if we were to put a PLOT_3D object into a PLOT attribute and 
  1049. try to add a DATA_SAMPLE to it. It fails because we have used inheritance 
  1050. to implement code re-use rather than subtyping, but have called a feature 
  1051. of the ancestor class on an object of the descendant class as if the 
  1052. descendant object were a true subtype. It is the compiler's job to detect 
  1053. and reject this error, to avoid the possibility of a run-time type error.
  1054.  
  1055. Here's another example where a real-world situation suggests a covariant 
  1056. solution. Herbivores eat plants. Cows are herbivores. Grass is a plant. 
  1057. Cows eat grass but not other plants.
  1058.  
  1059.    class HERBIVORE                               class PLANT
  1060.    feature
  1061.       eat(food: PLANT) is ...
  1062.       diet: LIST[PLANT]
  1063.  
  1064.    class COW                                     class GRASS
  1065.    inherit                                       inherit
  1066.       HERBIVORE                                     PLANT
  1067.          redefine eat
  1068.       end
  1069.    feature eat(food: GRASS) is ...
  1070.  
  1071. This does what we want. The compiler must stop us from putting a COW object 
  1072. into a HERBIVORE attribute and trying to feed it a PLANT, but we shouldn't 
  1073. be trying to do this anyway.
  1074.  
  1075. Also consider the container 'diet'. We are not forced to redefine this 
  1076. feature in descendant classes, because with covariant redefinition of the 
  1077. argument to 'eat', the feature 'diet' can always contain any object that 
  1078. can be eaten (e.g. grass for a cow). (With contravariant redefinition of 
  1079. the argument to 'eat', it would be necessary to re-open the parent class to 
  1080. make the type of the container 'diet' more general).
  1081.  
  1082. To summarise: Real-world problems often lend themselves to covariant 
  1083. solutions. Eiffel handles these well. Incorrect programs in the presence of 
  1084. covariant argument redefinition can cause run-time type errors unless the 
  1085. compiler catches these.
  1086.  
  1087. Sather uses the contravariant rule, but uses separate mechanisms for 
  1088. subtyping and code reuse and only allows dynamic binding on true subtypes. 
  1089. This seems to make contravariance work well, but it can force the Sather 
  1090. programmer to use concrete types when modelling covariant problems. 
  1091. Concrete types cannot be further subtyped in Sather, so this can reduce the 
  1092. potential for re-use (in Eiffel, any type can be further subtyped, but the 
  1093. compiler must check that it is used validly).
  1094.  
  1095. ----------
  1096.  
  1097. L06)   Is it true that there are "holes" in the Eiffel type system?
  1098.  
  1099. No. The design of Eiffel makes it possible to catch all type errors at 
  1100. compile time, so that an Eiffel program cannot abort with a run time type 
  1101. error.
  1102.  
  1103. However, to catch the more obscure type errors at compile time, the 
  1104. compiler must analyse the way that classes interact within the entire 
  1105. system, rather than just looking at each class one by one. This type of 
  1106. system-wide checking is also necessary for many compiler optimisations.
  1107.  
  1108. Because system-wide compile-time validity checking can be complex, some 
  1109. compilers insert run-time traps for these errors instead, and some may fail 
  1110. to correctly trap these errors. Ask your Eiffel compiler vendor how they 
  1111. handle these type problems.
  1112.  
  1113. ----------
  1114.  
  1115. L07)   Is there support for concurrency in Eiffel?
  1116.  
  1117. Eiffel 3 does not support concurrency; neither do current commercial 
  1118. compilers. However, work on concurrency is one of the hottest Eiffel-
  1119. related research topics.
  1120.  
  1121. For four articles on concurrency facilities for Eiffel, including Bertrand 
  1122. Meyer's article "Systematic Concurrent Object-Oriented Programming", see 
  1123. the September 1993 "Communications of the ACM" (Vol. 36, Number 9).
  1124.  
  1125. ----------
  1126.  
  1127. L08)   Why doesn't Eiffel allow function overloading?
  1128.  
  1129. In Eiffel, no two features of a class C may have the same identifier, 
  1130. regardless of their respective signatures.  The prevents the use of 
  1131. function overloading ("multiple polymorphism"), a common programming 
  1132. technique in languages like C++.
  1133.  
  1134. Eiffel is designed to be minimal: it includes exactly the features that its 
  1135. designer considered necessary, and nothing else.
  1136.  
  1137. Because Eiffel already supports (single) polymorphism through its 
  1138. inheritance system, the only positive thing that function overloading buys 
  1139. you is reducing the number of feature names you have to learn. This is at 
  1140. the expense of reducing the ability of the compiler to trap mistakes (often 
  1141. type errors).
  1142.  
  1143. Readability is also enhanced when overloading is not possible. With 
  1144. overloading you would need to consider the type of the arguments as well as 
  1145. the type of the target before you can work out which feature is called. 
  1146. With multiple inheritance and dynamic binding this is awkward for a 
  1147. compiler and error-prone for a human. There is no intuitive rule which 
  1148. could be used to disambiguate routine calls where there is no "nearest" 
  1149. routine.
  1150.  
  1151. However, in Eiffel it's easy to write one routine with arguments of the 
  1152. most general applicable type, then use the assignment attempt operator to 
  1153. carry out the appropriate operation according to the run-time type of the 
  1154. arguments (thereby explicitly programming the disambiguation "rules").
  1155.  
  1156. Having said that, the lack of multiple polymorphism does force us to write 
  1157. some common mathematical operations (e.g. matrix math) in an awkward way, 
  1158. and forces arithmetic expressions to be treated specially (the "arithmetic 
  1159. balancing rule", ETL p385). But no-one has come up with a solution which is 
  1160. so simple, elegant and useful that it improves the quality of Eiffel as a 
  1161. whole.
  1162.  
  1163. ----------
  1164.  
  1165. L09)   Why are there no procedural types in Eiffel?
  1166.  
  1167. The notion of allowing a routine to be passed as an argument to a routine 
  1168. is in many people's view incompatible with the O-O method. The definition 
  1169. of object-orientation implies that every operation belongs to an object 
  1170. type, so one does not manipulate routines just by themselves.
  1171.  
  1172. A possible technique when one feels the need to use a routine argument is 
  1173. to write a class and include the routine in it. Then (rather than passing a 
  1174. routine argument) pass an object - an instance of this class - to which the 
  1175. routine can then be applied. This is a more flexible approach in the long 
  1176. term. For example, you may later add an "undo" routine to your routine-
  1177. containing class, or an attribute such as "time of last execution".
  1178.  
  1179.  
  1180. -- 
  1181. -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK   | Ph 0772-687525
  1182. -- Everything Eiffel: compilers/libraries/publications | +44-772-687525
  1183.